1. Field of the Invention
The present invention relates generally to a mobile communication system supporting packet service. More particularly, the present invention relates to a method and apparatus which efficiently use radio resources by reducing the header size of a Protocol Data Unit (PDU) to be transmitted on a radio link.
2. Description of the Related Art
Today's mobile communication systems are evolving toward high-speed and high-quality wireless data packet communication systems. These systems are capable of providing data service and multimedia service in addition to the traditional voice service. A 3rd generation mobile communication system using Wideband Code Division Multiple Access (WCDMA) based on the European Global System for Mobile communications (GSM) system and General Packet Radio Services (GPRS), Universal Mobile Telecommunication Service (UMTS) provides mobile subscribers or computer users with a uniform service of transmitting packet-based text, digitized voice, and video and multimedia data at or above 2 Mbps regardless of their locations around the world. With the introduction of the concept of virtual access, the UMTS system allows access to any end point within a network all the time. The virtual access refers to packet-switched access using a packet protocol like Internet Protocol (IP).
Regarding voice service, a standardization organization for UMTS, 3rd Generation Partnership Project (3GPP) is discussing Voice over IP (VoIP). VoIP is a technology for sending a voice frame generated from an audio Coder and Decoder (CODEC) in the form of an IP/User Datagram Protocol (UDP)/Real-time Transport Protocol (RTP) packet. VoIP facilitates the provision of voice service over a packet network.
FIG. 1 illustrates the configuration of a typical mobile communication system supporting VoIP.
Referring to FIG. 1, a User Equipment (UE) 100 includes a CODEC 105 for converting a voice signal to a voice frame, an IP/UDP/RTP layer 104 for converting the voice frame to an IP/UDP/RTP frame, a Packet Data Convergence Protocol (PDCP) layer 103 for compressing the header of the IP/UDP/RTP packet, a Radio Link Control (RLC) layer 102 for converting the header-compressed IP/UDP/RTP packet to be suitable for transmission on a radio channel, and a Medium Access Control (MAC)/Physical (PHY) layer 101 for sending the output of the RLC layer 102 on the radio channel.
Radio data from the UE 100 is delivered to a Radio Network Controller (RNC) 120 via the PHY layer (not shown) of a Node B 110 on the radio channel. Like the UE 100. The RNC 120 is analogous to the UE 100 because it includes a MAC layer 121, an RLC layer 122, and a PDCP layer 123, for converting the radio data to the original IP/UDP/RTP packet and sending it to a Core Network (CN) 130. The IP/UDP/RTP packet is sent to the other party, for example, a receiving UE (not shown) via an IP network 140. The receiving UE a layer structure analogous to that of the transmitting UE 100 and recovers the original voice signal by processing the IP/UDP/RTP packet in the reverse order. The RLC layers 102 and 122 function as follows.
In general, the RLC layer works in Unacknowledged Mode (UM), Acknowledged Mode (AM), or Transparent Mode (TM). VoIP operates in the RLC UM.
In the transmitter, the RLC UM layer segments, concatenates, or pads RLC Service Data Units (SDUs) received from a higher layer to a size suitable for transmission on a radio channel. The RLC UM layer constructs an RLC PDU suitable for transmission on the radio channel by inserting segmentation/concatenation/padding information and a sequence number into the resulting data and provides the RLC PDU to a lower layer.
In the receiver, the RLC UM layer recovers data by interpreting the sequence number and segmentation/concatenation/padding information of an RLC PDU received from a lower layer and re-constructs an RLC SDU by concatenating or segmenting the data, in correspondence with the operation of the transmitter. The reconstructed RLC SDU is provided to a higher layer. Processing an RLC SDU received from the higher layer to a size suitable for transmission on a radio channel is called ‘RLC framing’.
FIG. 2A illustrates conventional RLC framing in a transmitter.
In FIG. 2, an RLC layer 210 frames data received from a higher layer 205 to a suitable data size for transmission on a radio channel. A lower layer 215 sends the framed data to a receiver on the radio channel. The higher layer 205 corresponds to a PDCP layer and the lower layer 215 corresponds to a MAC layer. The data exchanged between the RLC layer 210 and the higher layer 205 is an ‘RLC SDU’ and the data exchanged between the RLC layer 210 and the lower layer 215 is an ‘RLC PDU’.
FIG. 2B illustrates conventional RLC framing in a receiver.
Referring to FIG. 2B, an RLC layer 212 recovers the original data from data received from a lower layer 217 and provides the recovered data to a higher layer 207. The higher layer 207 corresponds to a PDCP layer and the lower layer 217 corresponds to a MAC layer. The data exchanged between the RLC layer 212 and the higher layer 207 is an ‘RLC SDU’ and the data exchanged between the RLC layer 212 and the lower layer 217 is an ‘RLC PDU’.
FIG. 2C illustrates a conventional operation for constructing RLC PDUs by framing of RLC SDUs in the RLC layer of the transmitter.
With reference to FIG. 2C, the RLC layer of the transmitter receives an RLC SDU 225 of a particular size, for example, a 100-byte IP packet from the higher layer. If a data size transmittable on a radio channel is 40 bytes, the RLC layer segments the RLC SDU 225 into three RLC PDUs 230, 235 and 240. Each RLC PDU may have 40 bytes. Each RLC PDU also includes an RLC header 245.
The RLC header 245 includes a Sequence Number (SN) 250, an E field 255, and at least one of a plurality of pairs of Length Indicator (LI) field 260 and E field 265. The LI field 260 is included according to segmentation. The SN field 250 indicates a 7-bit SN which increases monotonously by 1 for every RLC PDU. SNs indicate the sequence of the RLC PDUs 230, 235 and 240. The E field 255, which is one bit, indicates whether the following field is a Data field or an LI-E pair field.
The LI field 260 is 7 bits or 15 bits in size depending on RLC framing. It indicates the position of a segment of the RLC SDU 225 in a Data field 270 of the RLC PDU. The LI field 260 indicates the start and end of the RLC SDU 225 within the Data field 270 of the RLC PDU. The LI field 260 may also indicate whether padding is used. The LI field 260 is set to a value expressed in bytes, indicating the number of bytes to the end of an RLC SDU from an RLC header. For simplicity, the LI field 260 is assumed to be 7 bits.
In the first byte of the first RLC PDU 230, the SN is set to a predetermined value ‘x’ and the first E is set to ‘1’, which implies that an LI-E pair resides in the following byte. In the second byte of the RLC PDU 230, the LI field indicates that the RLC SDU 225 starts from the first byte of the Data field of the RLC PDU 230. This allows the LI field to be used in other ways rather than just indicating the position of the last byte of the RLC SDU. This LI is called ‘pre-defined LI’. Pre-defined LIs are discussed below.
‘1111 100’: the first byte of the Data field in the RLC PDU is the first byte of the RLC SDU.
‘0000 000’: although the last byte of the RLC SDU is included in the previous RLC PDU, an LI indicating that it is not included in the previous RLC PDU.
‘1111 111’: the remainder of the Data field of the RLC PDU are padding bits.
Hence, the first LI field is set to the pre-defined LI ‘1111 100’ and ‘0’ is inserted in the second E field to indicate that the next byte belongs to the Data field in the RLC PDU 230. Accordingly, a 38-byte Data field of the 40-byte RLC PDU 230, except for the first two bytes, is used to carry the first 38 bytes of the RLC SDU 225.
In the second RLC PDU 235, the SN is set to ‘x+1’ and the E is set to ‘0’ indicating that the next byte is for the Data in the first byte. Since the RLC PDU 235 does not include the first byte or the last byte of the RLC SDU 225, there is no need to include an LI field. Therefore, the remaining 39 bytes of the Data field carry 39 bytes of the RLC SDU 225, from byte 39 to byte 77.
In the third RLC PDU 240, the SN is set to ‘x+2’ and the E is set to ‘1’ indicating that the next byte is an LI-E pair in the first byte. In the second byte, the LI is set to ‘0010 111(=23)’ indicating that the last byte of the RLC SDU 225 corresponds to the 23th byte (‘100’−‘77’) of the Data field, and the E field is set to ‘1’. The Data field of the RLC PDU 240 still has room to carry data, after loading the last segment of the 100-byte RLC SDU 225. Therefore, the second E field is set to ‘1’ and the second LI field is set to ‘1111 111’, which implies that bits following the position indicated by the first LI field are padded. The third E field is set to ‘0’. Consequently, the Data field of the RLC PDU 240 is filled with the last 23 bytes of the RLC SDU 225 and a 14-byte padding.
In accordance with the above RLC layer operation of the transmitter, the RLC layer of the receiver operates as follows.
The RLC layer of the receiver receives the RLC PDUs 230, 235 and 240 and sequentially orders them based on their SNs. Specifically, the RLC layer determines that the Data field of the first RLC PDU 230 corresponds to the first segment of the RLC SDU 225 referring to the LI field of the RLC PDU 230, and the Data field of the second RLC PDU 235 corresponds to the second segment of the RLC SDU 225 referring to the LI field of the RLC PDU 235, thus considering that reconstruction of the RLC SDU 235 is yet to be completed. Then the RLC layer determines from the first LI field of the RLC PDU 240 that 23 bytes of the Data field of the RLC PDU 240 are the last segment of the RLC SDU 225, and completes reconstruction of the RLC SDU 225 by combining the segments extracted from the three RLC PDUs 230, 235 and 240. In this process, the RLC layer recognizes from the second LI that the remaining bits of the Data field of the RLC PDU 240 are padded bits.
The conventional scheme in which the last byte of an RLC SDU is indicated by an LI is efficient in cases where one RLC SDUI is segmented to a plurality of RLC PDUs or a plurality of RLC SDUs are concatenated to one RLC PDU. However, one concrete RLC SDU frequently corresponds to one RLC PDU without any segmentation/concatenation/padding in view of the nature of VoIP packets.
In cases where a 12.2-kbps Adaptive Multi-Rate (AMR) CODEC is widely used in 3GPP, this AMR CODEC creates a 7-byte or 32-byte voice frame every 20 msec. The voice frame is encapsulated with an IP/UDP/RTP header, header-compressed in the PDCP layer, and then delivered to the RLC layer. The compressed header is typically 3 bytes, or occasionally ranges from 4 to 12 bytes.
Consequently, the size of an RLC SDU ranges from 10 to 19 bytes, or from 35 to 44 bytes. This RLC SDU is provided to the RLC layer of the transmitter every 20 msec. The RLC layer reconstructs one concrete RLS SDU to one RLC PDU and sends it on a radio channel. As stated above, since the compressed header is usually 3 bytes in length, most RLC SDUs are 10 or 35 bytes. Accordingly, it is preferable to determine an RLC PDU size such that RLC SDUs of the most frequent size can be efficiently processed.
If the RLC PDU size is defined based on the most frequent RLS SDU size, most of RLS SDUs are framed to RLC PDUs without segmentation/concatenation/padding. In this case, the conventional framing is not efficient.
FIG. 3 illustrates a problem encountered with the conventional framing.
Referring to FIG. 3, a 35-byte RLC SDU 305 is created and the size of an RLC PDU 310 is 38 bytes. The RLC SDU 305 is framed to one RLC PDU 310. In the RLC PDU 310, a first LI 315 is set to ‘1111 100’ which indicates that the first byte of the RLS SDU 305 corresponds to the first byte of a Data field 325 and a second LI 320 is set to ‘0100 011’ which indicates that the last byte of the RLS SDU 305 corresponds to the 35th byte of the Data field 325. The Data field 325 carries the entire 35-byte RLC SDU 305.
Transmission of the 35-byte is accompanied by a 3-byte overhead, two bytes of which are used for the LI fields.
As described above, compared to typical packet communications, packet data needs to be processed in real time and one RLC SDU is created at every predetermined time interval in VoIP. More specifically, one RLC SDU is converted to one RLC PDU without segmentation or concatenation in VoIP communications. Nonetheless, the conventional RLC framing always requires at least two LI fields, i.e. an LI indicating the start of an RLC SDU and another LI indicating the end of the RLC SDU for an RLC PDU. When necessary, an LI indicating whether a Data field is padded is additionally inserted.
Therefore, the conventional RLC framing leads to inefficient use of limited radio resources in VoIP due to the use of unnecessary LI fields.
Accordingly, there is a need for an improved system and method to efficiently use radio resources.